HELLOFRESH 定量可用性測試/問卷調查
| 型別（TYPE） | 主題（SUBJECT） | 專案規模（PROJECT SIZE） |
|---|---|---|
| App | 電商/訂閱 | 中型 |
| 指標（Metric） | 改版前（Before） | 改版後（After） | 改進分數（Improvement Score） | 百分比變化（Percent Change） |
|---|---|---|---|---|
| SUS（系統可用性評分） | 75 | 90 | 提高 20% | — |
| 任務完成時間（Time on task） | 28 | 14 | 提高 100% | -50% |
| 主觀成功率（Subjective success rate） | 63% | 100% | 提高 59% | — |
| 成功率（Success rate） | 25% | 100% | 提高 300% | — |
| 易用性評分（Ease-of-use rating） | 6.1 / 7 | 6.9 / 7 | 提高 13% | — |
| 信心評分（Confidence rating） | 5.9 / 7 | 6.9 / 7 | 提高 17% | — |
我們當時在做 HelloFresh 的App頁面最佳化，說實話，專案剛啟動那會兒，整個團隊都覺得：“不就一個訂餐App的主頁嘛，應該很簡單。”但真正開始調研以後才發現，問題一點都不簡單，使用者的混亂程度，完全超出我們的預期。
HelloFresh 這家公司大家應該都知道，總部在柏林，是全美最大的家庭餐包配送平臺，訂閱使用者遍佈美國、加拿大、歐洲和澳洲。使用者每週會收到不同菜譜和食材包，可以在App裡查訂單、改菜、跳過配送，基本就是圍繞一週一週的“訂閱週期”來操作的。
但使用者用得好嗎？我們一上來做了一輪定性調研和問卷，結果很一致——很多人搞不清楚“這周”和“下週”的餐到底是哪個，過去吃過的和未來要收的又混在一起。尤其在主介面，使用者經常不知道什麼時候還能修改訂單，結果就錯過了編輯時間，一肚子不爽。我們甚至看到使用者問：“HelloFresh的‘一週’到底從哪天開始算？”
James Villacci 是我們團隊的UX Research Lead，他總結得很準確：“核心問題在於，App主頁沒有明確告訴使用者哪些是‘過去的餐’，哪些是‘未來還能改的餐’。”
我們決定從兩方面入手做設計最佳化。
一方面，內容層面上，我們重新定義了“時間組別”，把所有配送分成兩大類：“Open deliveries”（還能改的）和“Closed deliveries”（已經鎖單了）。比如“Next upcoming delivery”是馬上要送的、還來得及改選單的，我們在視覺上用了大圖來重點突出；而“Following upcoming delivery”是幾周之後送的，就用小縮圖，降低視覺權重，提醒使用者這部分不著急；“Current delivery”是本週已經送到家的，就歸到過去的訂單裡，使用者只能看不能改；還有“Shipping soon”的，我們會提醒說太晚了，來不及改了。
另一方面，視覺層面我們也下了功夫。整個主頁重新做了資訊層級，未來每週的送餐狀態我們都給了不同的視覺處理方式，越接近現在、越能修改的越明顯。比如“Edit meals”按鈕就在“Next week”卡片下方醒目地放著，過去的訂單就收起來，不再展示菜品縮圖，避免干擾。
效果非常顯著。
我們在新版上線之後做了一輪定量可用性測試，用的是SUS打分、成功率、用時、信心評分這些標準，和舊版對比。光是完成“你想看看5月12號那單送了什麼”的任務，用時直接少了50%，主觀成功率提高了59%，SUS系統可用性得分漲了20%。原來只有四分之一使用者能完成這個任務，現在是100%。最讓我震撼的是“信心評分”也提高了17%，說明使用者不僅能用，還覺得自己掌握了這個系統。
這次最佳化讓我特別有感觸的一點是，很多時候我們以為“頁面看起來還行”，但當你真的去觀察使用者怎麼用，去問他們“你知道還能改幾天的訂單嗎”“你覺得這裡的‘這周’是周幾開始的”，他們的回答常常會讓你意識到，我們所謂的“清晰”，在使用者那裡完全不是這麼回事。
這才是設計真正該解決的問題。不是炫技，而是讓人用起來心裡有數、手上有底。